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A SYSTEM AND METHOD FOR REPRESENTING COMPRESSED INFORMATION 



1. Field of Invention 

The invention relates to a system and method for representing compressed 
information within a data stream. 

2. Description of Related Art 

Currently, numerous standards exist for encoding data for transmission across a 
channel to a receiver (decoder). For example, the International Standard ISO/IEC 13818- 
7, Advanced Audio Coding, also known as MPEG-2 AAC, specifies a syntax for 
representing compressed audio signals which are suitable for transmission over limited 
bandwidth channels. The same syntax with one minor backwards compatible extension is 
International Standard ISO/IEC 14496-3, also known as MPEG-4 audio. Because these 
standards typically address transmission of the compressed data over bit-serial channels 
(e.g., a radio modem channel) the compressed format is often referred to as a bitstream, 
although the standard is equally valid for other transmissions or storage formats. 

Current standards for representing compressed data in a data stream may not 
support re-synchronization of the bitstream and a decoder. Additionally, current 
standards may not provide for any explicit form of error detection, error control, of error 
recovery. For example with existing protocols, such as MPEG-2 AAC, it is necessary for 
the decoder to know the beginning of a received stream of raw data in order for the 
decoder to be able to decode the raw data. While information for synchronization of a 
decoder to a raw data stream is available in applications, such as receiving a computer file 
from a hard drive or the like, in many applications the synchronization information is not 
available. For example, in satellite or digital radio communications, the decoder can 
begin to receive the signal at any point during the signal transmission. Accordingly, the 
decoder needs to be able to synchronize with the signal in order to properly decode the 
signal. 

One solution to resolving the synchronization problem, is to provide a separate 
synchronization channel in parallel to the data channel. An example of this technique 
could include having a decoder receive a first data stream containing video data, a second 
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data stream containing audio data and a third data stream containing synchronization 
data. Accordingly, the decoder may then use the synchronization data to decode and 
synchronize with both the audio and video data. However, such systems can become 
very complicated since the decoder must receive and process numerous different signals. 

Accordingly, there exists a need for providing a method for representing 
compressed information which provides for re-synchronization along with error detection 
and error correction. 



In the Advanced Audio Coding (AAC) syntax, for example, the bitstreams which 
represent a contiguous interval in the signal time domain can be represented as a series of 
contiguous raw datablocks in the compressed time domain. The raw datablocks can 
include a series of elements, such as a single channel element (SCE), a channel pair 
element (CPE), a coupling channel element (CCE), a lfe channel element (LFE), a data 
stream element (DSE), a program config element (PCE) and a fill element (FIL). 

Of particular interest is the DSE, or data stream element, which is composed of a 
DSE ID, an element instance tag, a data byte align flag, a count, an Esc count, and a 
series of data stream bytes. For the DSE, the MPEG-2 AAC standard specifies the length 
and interpretation of the DSE ID, an element instance tag, the databyte align flag, the 
count and the ESC count. However, the MPEG-2 AAC standard only specifies the 
length, but not the interpretation of the data stream bytes. Furthermore, the value of 
count is equal to the number of data stream bytes that are present in the DSE. 
Accordingly, the MPEG-2 AAC syntax, and associated semantics, permits the DSE block 
to carry a number of bytes of information (i.e., "count" occurrences of "data stream byte") 
whose meaning can be unknown to a standards compliant AAC decoder. By doing so the 
AAC standard is capable of being extended on a user-specified basis. 

The present invention is a method for using the DSE block to give a bitstream of 
compressed data a re-synchronization, error detection, error control and/or error recovery 
capabilities while still maintaining full compliance to a standard, such as the MPEG-2 
AAC standard. Accordingly, the present invention provides a system and method for 
storing re-synchronization, error correction and/or error detection data within an existing 
communication protocol, while still complying with the existing protocol's requirements. 
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By doing so, data information can still be passed from an encoder to a decoder via a 
channel using an existing and well known standard transport protocol. However, the 
existing well known transport protocol can now include the data necessary for 
synchronization of the decoder to the received raw data, along with error detection and 
error correction by the decoder. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention is described in detail with regards to the following Figures, in 
which like elements are referred to with like numerals, and in which: 

Figure 1 is an exemplary block diagram showing the transmission of compressed 
data over a channel according to the present invention; 

Figure 2 is an exemplary block diagram of a bitstream of data according to the 
present invention; 

Figure 3 is a flowchart outlining an exemplary process of encoding data according 
to the present invention; and 

Figure 4 is a flowchart outlining an exemplary process of decoding compressed 
data according to the present invention. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

Figure 1 is an exemplary block diagram of a data transmission system 100 
according to the present invention. As shown in Figure 1, the system 100 includes a 
transmitter 102 capable of transmitting compressed data across a channel 104 to a 
receiver 106. The transmitter 102 includes an encoder 108 and a channel formatter 110. 
The receiver 106 includes a channel de-formatter 112 and a decoder 114. 

In operation, data is input into the transmitter 102 from a data source (not shown). 
The input data can be any form of data, such as audio data, video data and/or textual data 
which is to be transmitted to the receiver 106: The input data is received by the encoder 
108 which may be any device capable of compressing the input data. In compressing the 
data, the encoder 108 needs to include a mechanism for the transmission of "user data" in 
a private data portion of a data stream. Examples of standardized methods for 
representation of compressed data that have a such a private data portion are ISO/IEC 
13818-7, MPEG-2 Advanced Audio Coding (AAC), and ISO/IEC 14496-3, and 
specifically MPEG-4 General Audio Coding. Both of these standard formats support the 
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transmission of "user data" via the data stream element PSE) mechanism. The user data 
mechanism permits the transmitted bitstream to contain private data that need not be 
interpreted by standard decoders, but may be interpreted by enhanced decoders. The 
invention applies to the case of enhanced decoders, in which the user data may contain 
information on how to achieve and maintain encoder and decoder synchronization. The 
user data may also contain information that can determined whether any transmitted bits 
were received in error, or information that will help minimize the perceived audio 
degradation that may result from transmission bit errors. Once complete, the encoder 102 
can transmit the compressed input data to the channel formatter 110. 

The channel formatter 110 formats the compressed data into a format that is most 
suitable for transmission over the channel 104. For example, formats can include a radio 
modulator in the case of a radio transmission channel, or a packet assembler in the case of 
a packet data channel. The channel formatter 1 10 then transmits the formatted 
compressed data across the channel 104 to the receiver 106. 

The channel 1 04 may be any type of medium that allows for the transmission of 
formatted compressed data from the transmitter 102 to the receiver 106. Furthermore, it 
is important to note that the channel 104 may be prone to errors in transmission. These 
errors may manifest as incorrect bits or bytes, or lost or missing bits or bytes. Some 
examples of possible channels 104 include conventional telephone lines, fiber optic lines, 
direct serial and parallel connections, cellular telephone connections, satellite 
communication links, radio frequency (RF) links, local area networks (LANs), intranets 
and the like. 

The formatted compressed data is received by the receiver 106 and input into the 
channel de-formatter 112. The channel de- formatter 1 12 can be any device capable of 
performing the inverse formatting of the channel formatter 110. For example, the 
channel de-formatter 112 can be a radio de-modulator in the case of a radio transmission 
channel packet gatherer in the case of a packet data channel. The channel de-formatter 
1 12 then transmits the de- formatted compressed data to the decoder 1 14. 

The decoder 114 can be any device that re-constructs the data received from the 
compressed data format to an uncompressed format. For example, the decoder 114 may 
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be an ISO/IEC 13818-7 MPEG-2 AAC decoder. The decoder then transmits the 
reconstructed data to an output of the receiver 106 for further processing. 

In a particular embodiment of the invention, the transmitter 102 is always on and 
transmitting formatted compressed data on the channel 104. At some point in time, the 
receiver 106 begins receiving the formatted compressed data at an arbitrary point in the 
stream of formatted compressed data. In order for the decoder to recognize the data, the 
decoder 1 1 4 must be able to recognize the appropriate point in the data stream to begin 
decoding. The compressed data stream is typically engineered such that these "break-in" 
points occur many times per second. Identifying the "break-in" points is referred to as 
synchronization of the encoder 108 and the decoder 114. 

As an example of operation, assume that the channel 104 is a terrestrial radio 
channel, and that the channel formatter 1 10 is actually a modem, which converts 
compressed data bits into signal tones for transmission over the channel 1 04. The 
channel formatter 110 may also apply some error protection prior to modulation. The 
channel de- formatter 112 does the inverse, including a possible error correction after de- 
modulation. If the channel 104 delivers errored bits, then the error correction may correct 
all errors, or in the case of a very bad channel condition, it may not, so that the errored 
data is delivered to the decoder 1 14. If the modem does not enforce byte 
synchronization, then the decoder 1 14 must scan all incoming bits and find an appropriate 
bit at which to begin decoding the audio. If the modem does enforce byte 
synchronization, then the decoder 114 must only scan all incoming bytes, which is less 
work. 

For an alternative example, assume that the formatter is a radio modem with 
forward error correction. The receiver begins examining the received bitstream at an 
arbitrary point in the bitstream, for example, a radio receiver has just tuned to the 
transmission frequency after the transmission was already in progress. In the most 
general case, the receiver begins examining a arbitrary bit. If byte synchronization is 
maintained across the radio channel, the receiver begins examining the most significant 
bit of an arbitrary byte. The first task is for the decoder to synchronize with the encoder. 
This is achieved by the decoder identifying the synchword that is in the transport DSE. 
Once this is done, the meaning of subsequent bits in the bitstream are known and 
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decoding can progress. If additional robustness against synchword emulation is desired, 
then two or more synchwords can be identified prior to decoding. A block_len field can 
be used to skip over a current raw_data_block directly to the next synchword without 
having to actually parse the bitstream information. 

If the radio demodulator does not report bit errors, then a block_crc field can be 
used to check the integrity of the raw_data_block as a whole. If this fails, then one option 
is to skip the entire raw_data_block by using the block_len field, and to resume decoding 
on a next raw_data_block. Since ACC does not have a fixed number of bits per 
raw_data_block, the blockjen field permits the decoder to maintain synchronization to 
the encoder even in the presence of bit errors. Another option in the case of a b!ock_crc 
failure is for ele_crc fields to be used to check the integrity of each element in the 
raw_data_block (those relevant elements are shown in Fig. 2, blocks 204-214). The 
beginning of each element can be determined by a ele_bit_len field. In this manner, a bit 
error in one element can be isolated to that element, and all other elements can be 
successfully decoded. 

In a second example, the channel 1 04 is a packet network, such as the Internet. 
The channel formatter 1 10 is a device that formats the compressed data into packets. The 
channel de-formatter 112 collects the packets, possibly putting them back in the correct 
order, and delivers the correctly ordered payloads of compressed data to the decoder 1 14. 
The channel formatter 110 and channel de-formatter 112 may also implement some sort 
of error control protocol, such as re-transmission of packets that are not received or are 
received with errors. 

If the encoder 108 delimits each raw datablock for the channel formatter 1 10, and 
if the channel formatter 110 forces each packet delivered to the channel 104 to be exactly 
one raw datablock, and if the channel de-formatter 112 also delimits each raw datablock 
received, then the decoder 1 14 re-synchronization is just to start decoding at the 
beginning of any (delimited) raw datablock. However, if the encoder 108 does not 
delimit the raw datablock for the formatter 110, then channel packetization is 
asynchronous with the delimitation of the raw datablocks in the compressed data stream. 
In this case, the decoder 1 14 must search every byte in its received packets (packets 
typically preserve byte synchronization) to find the start of a raw datablock. 
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In the case that a raw_data_block is fragmented across several transport channel 
packets, and one of those packets is received in error, the information in the transport 
DSE can be used to decode much of the information that was received. The general 
mechanism is very similar to the methods already presented above for the radio modem 
channel. 

Figure 2 shows an exemplary bitstream 200 of data which the decoder 1 14 may 
receive via the channel 106 from the transmitter 102. While the data in the bitstream 200 
is in an MPEG-2 AAC format, it is to be understood that any other protocols that 
provides a private data portion to hold "user data" can be used without departing from the 
spirit and scope of the present invention. 

The bitstream 200 is composed of a series of frames or raw data blocks 202. The 
frames 202 are further composed of elements 204-218 which are defined by the MPEG-2 
standard. 

As shown in Figure 2, the data stream element (DSE) 212 which is composed of a 
DSE ID 220, an element instance tag 222, a data byte align flag 224, a count 226, an Esc 
count 228, and a data stream byte 230. In the DSE 212, the MPEG-2 AAC standard 
specifies the length and interpretation of the DSE ID 220, the element instance tag 222, 
the databyte align flag 224, the count 226 and the Esc count 228. However, the MPEG-2 
AAC standard only specifies the length and not the interpretation of the data stream bytes 
230. Furthermore, the value of count is equal to the number of data stream bytes that are 
present in the bitstream. 

Accordingly, the MPEG-2 AAC syntax, and associated semantics, permits the 
DSE block 212 to carry a number of bytes of information (i.e., "count 0 occurrences of 
"data stream byte blocks") whose meaning can be unknown to a standards compliant 
AAC decoder. By doing so the AAC standard is capable of being extended on a user- 
specified basis. The DSE block 212 can be used to give a bitstream 200 of compressed 
data a re-synchronization, error detection, error control and/or error recovery capabilities 
while still maintaining full compliance to a standard, such as the MPEG-2 AAC 
standard. Therefore, the technique can store re-synchronization, error correction and/or 
error detection data within an existing communication protocol, while still complying 
with the existing protocol's requirements. 
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The DSE ID field 220 is used to identify the DSE 212 from the other elements 
204-210, 214-218 in the frame 202. 

The Element Instance Tag field 222 is used to identify the type of data which the 
DSE 212 is being used to store by predefining a set of data types and a corresponding ID. 
For example, if the Element Instance Tag were equal to "3", then the data in DSE 212 
may be text data, such as the lyrics to a song for which the other elements 204-210, 214- 
216 are carrying the corresponding audio data portion. Alternatively, if the Element 
Instance Tag field 222 were equal to "15", then the DSE 212 can be carrying data related 
to synchronization, error detection or error correction. 

The Data Byte Align Flag field 224 can be used to force the data stream bytes to 
have the same byte framing in the bitstream as the first byte in the raw data stream. 

The Count field 226 can be equal to and used to store the number of bytes in the 
DSE payload. 

The Esc Count field 228 is optional, and can be used to extend the range of the 
Count Field 226. 

The Data Stream Byte field 230 is the DSE payload and is the user data in this 
discussion. 

In operation, the transmitter 102 begins transmitting a signal across the channel 
104. Subsequently, the receiver 106 begins to receive the transmitted signal at a random 
point in time. As discussed previously, and also as presented in Fig. 4 below, the decoder 
1 14 would first synchronize with the encoder 108, after which decoding would begin. If 
there were transmission bit, byte or packet errors, then as previously discussed, the 
information in the transport DSE could be used to maintain synchronization and to 
decode most of the information in a raw_data_block that was received correctly. 

Figure 3 is a flowchart of an exemplary process of encoding input data received 
by the transmitter 102. For the purposes of this discussion the input data is audio data, 
however, it is to be understood that the data may be any type. The process begins in step 
300 and proceeds to step 302. 

In step 302, the input data is received from a data source. As described in block 
302, the input data can take the form of a segment of an audio wave form. The process 
then proceeds to step 304. 
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In step 304, the input data is compressed by an encoder to form a compressed 
representation of the data. The process then proceeds to step 306. 

In step 306, the side information is calculated. The detail of the side information 
can vary, and may contain information such as the blockjen, block_CRC, and possibly 
element_bit_len and ele_crc, as discussed above. The process then proceeds to step 308. 

In step 308, the side information is packed into the payload bytes of the DSE, for 
example the user data, and the payload byte count in the DSE is adjusted accordingly. 
The DSE may typically be output first, prior to any other information in the raw data 
block. The process then proceeds to step 310. 

In step 310, the encoded data is transmitted across a channel. Control then returns 
to step 302 where the process may be repeated. 

Figure 4 is a flowchart of an exemplary process of decoding a bitstream of the 
present invention. The process begins in step 400 where a decoder begins to examine a 
bitstream. The process then proceeds to step 402. 

In step 402, the bitstream is further examined by the decoder to determine whether 
a window of bits is equal to a synchword. If the window of bits is equal to the 
synchword, then the bitstream is a data stream element (DSE) and the process proceeds to 
step 406; otherwise the process proceeds to step 404. In step 404 the bitstream is shifted 
ahead by one bit and the process returns to step 402 where the decoder determines 
whether the next window of bits is a synchword. 

In step 406, the decoder has recognized a synchword in the bitstream and the 
remaining portion of the user data in the DSE is parsed by the decoder. Information 
parsed is used immediately, in the case of synchronization, or is saved for possible future 
use, in the case of error recovery. The process then proceeds to step 408. 

In step 408, the decoder gets an ID from the bitstream. Next, in step 410, the 
decoder checks to see if the ID corresponds to that of the DSE. If the ID is the DSE ID 
then the process proceeds to step 414; otherwise the process proceeds to step 412. In step 
412, the element is not the DSE, and therefore the decoder decodes the other appropriate 
element, such as SCE 204, CPE 206, CCE 208, LFE 210, PCE 214, FIL 216 and ID END 
2 1 8. After step 4 12, the process then returns to step 408 where a next ID is examined. 
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In step 414, the decoder gets a tag from the DSE. The process then proceeds to 
step 416, where the tag is examined to see if it corresponds to a transport tag value. If the 
tag corresponds to the transport tag, then the process proceeds to step 418; otherwise, the 

process proceeds to step 417. 

In step 417, the remainder of the DSE is parsed in the standard manner, and the 

process returns to step 408. 

In step 418, the specified field are parsed. At this point, the next bit to be 
examined is the first bit in the Data Stream Byte field, and the process returns to step 402. 

While this invention has been described with specific embodiments thereof, it is 
evident that many alternatives, modifications, and variations will be apparent to those 
skilled in the art. Accordingly, the preferred embodiments of the invention as set forth 
herein are intended to be illustrative, not limiting. Various changes may be made without 
departing from the spirit and scope of the present invention. 



